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For: Tagging Mechanism for Data Path 
Security Processing 

Arguments to Accompany the Pre-Appeal Brief Request for Review 



Applicants hereby submit the following Arguments, in five (5) or less total pages, 
as attachment to the Pre-Appeal Brief Request for Review Form (PTO/SB/33). A Notice 
of Appeal is concurrently filed. 



Applicants' arguments in the Amendment and Reply under 37 C.F.R. §1.111 filed 
on July 6, 2009 (hereinafter "Reply"), were not properly considered or responded to by 
the Examiner in the final Office Action mailed October 14, 2009 ("Final Office Action"). 
1. Objection to the Specification and Rejections under 35 U.S.C. §112 

In the Final Office Action, the Examiner objected to the specification as failing 
"to provide proper antecedent basis for the recitations (or essentially similar recitations) 
'a user-specific type field.'" The Examiner further rejected claims 5-7, 9, 1 8, 30, 35, 36, 
38 under 35 U.S.C. 1 12, second paragraph as being indefinite. Specifically, the 
Examiner stated that "the claim recitation of 6 . . . a user-specific type field . . . ' or 6 . . . a 
user-specific Ethernet type' lacks a defined and customary meaning to those of ordinary 
skill in the art and the applicant's fail to define 'a user-specific type field', thereby 
rendering the scope of the claims indeterminate." (Final Office Action, p. 6). Applicants 
traverse. 

As discussed in MPEP 2173.05(e), "[t]he mere fact that a term or phrase used in 
the claim has no antecedent basis in the specification disclosure does not mean, 
necessarily, that the term or phrase is indefinite. There is no requirement that the words 
in the claim must match those used in the specification disclosure. Applicants are given a 
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great deal of latitude in how they choose to define their invention so long as the terms 

and phrases used define the invention with a reasonable degree of clarity and precision." 

Paragraph [0060] of Applicants' specification recites: 

When the security processor receives a packet 60 with the security 
processor's address in the DA field of the outer header 66, the security 
processor may check the Ethernet type field 62 to determine how to 
process the packet header. A company such as Broadcom Corporation 
may have a unique registered Ethernet type 62 that is used to define in- 
band packet communication. 

Thus, the specification describes that a user (e.g., "Broadcom") may have a unique 
registered Ethernet type 62. That is, this unique registered Ethernet type is user-specific. 
Accordingly, the term "user-specific Ethernet type field" is defined with reasonable 
clarity and precision and is therefore not indefinite. 

The Examiner further objected to the specification as failing "to provide proper 
antecedent basis for the recitations of 'pre-populated with an address . . . ' and 'the pre- 
populated header' as found recited within claim 1 7" and recitations (or essentially 
similar recitations) in claims 1,17, 26, and 37 related to a destination address of the 
second Ethernet packet being an address of the originating device. (Final Office Action, 
pp. 2-3.) 

The Examiner similarly rejected claims 1-7, 9, 13-33 and 35-40 under 35 U.S.C. 

1 12, first paragraph as failing to comply with the written description requirement stating 

that "Applicant has not clearly pointed out where the new (or amended) claim is 

supported, nor does there appear to be a written description of the claim limitations in the 

application as filed" and under 35 U.S.C. 112, second paragraph, as being indefinite for 

failing to particularly point out and distinctly claim the subject matter which applicant 

regards as the invention. Specifically, the Examiner stated that: 

the examiner interprets the applicant's amendments in light of the 
applicant's arguments, wherein the applicant asserts that the claimed 
features are supported within the applicant's disclosure (e.g., par. 64, 65) 
within the context of configuration packets for the configuration of a 
security processor. However, the examiner points out that security 
processor configuration and IPSec communication are distinct processes. 
Thus, the scope of these claims is indefinite, as it is unclear what process 
the applicant is attempting to claim. 

Applicants respectfully disagree with the Examiner's understanding of the specification. 
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As described in Applicants' specification, "CLASS-F packet 72 may be used to 
send configuration packets and data packets to the security processor." (Spec, ]f [0064]." 
"Each device builds the packet that will be sent back to the device. The security processor 
may then simply strip the outer header and the security header (F, C, MCW), modify the 
packet data (SAP, MAP, MEP, DATA), if applicable, and send the inner packet back to 
the device." (Spec, f [0065].) "The inner Ethernet header is a header that may be used to 
return the packet to the original sender. Thus, the DA [destination address] in the inner 
Ethernet header may be the address of an Ethernet controller that sent a configuration 
packet or data packet to the security processor." (Spec, \ [0064].) 

Applicants' specification further describes that "a previously encapsulated packet 
may be sent to the security processor 810 using the CLASS -FAMILY=security packet 
type. This packet will be encrypted/authenticated by the security processor 8 1 0 using 
the security association data ("SAData") stored either in local memory or passed in-band 
with the packet." (Spec, % [0135].) 

Thus, the specification provides proper antecedent basis and written description 

support for the elements of claims 1,17, 26, and 37 including: 

"a first Ethernet packet from an originating device, the first Ethernet packet 
comprising a second Ethernet packet . . . wherein a destination address of the 
second Ethernet packet is an address of the originating device," as recited in 
independent claim 1 ; 

"the first Ethernet packet comprising a second Ethernet packet having a 
header pre-populated with an address of the originating device as the destination 
address, ... " and " returning the second Ethernet packet to the originating 
device, wherein the returned second Ethernet packet includes the pre-populated 
header and the encrypted packet data," as recited in independent claim 17; 

"generating a first Ethernet packet, wherein the first Ethernet packet includes 
a header having an address of the originating device as the destination address 
and packet data ... generating a second Ethernet packet encapsulating the 
memory address and the first Ethernet packet, wherein the second Ethernet 
packet includes a header having an address of the security processor as the 
destination address, . . .," as recited in independent claim 26; 

and "a first Ethernet packet received from an originating device, the first 
Ethernet packet comprising a second Ethernet packet including a header having 
an address of the originating device as the destination address ..." and "a unit 
configured to transmit the second Ethernet packet, including the at least a portion 
encrypted by the encryption processor, to the originating device" as recited in 
independent claim 37. 
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Furthermore, these claims and their associated dependent claims are clearly supported by 
the specification and are therefore not indefinite. Based on the above, Applicants 
respectfully request that the objections to the specification and rejection of the claims 
under 25 U.S.C 112 first and second paragraphs be withdrawn. 
2. Rejections under 35 U.S.C. §103 

Claims 1-4, 13-15, 16, and 37 were rejected under 35 U.S.C. § 103(a) as 
allegedly being unpatentable over Bryers et al., U.S. Patent Published Application No. 
2003/0126233 ("Bryers"), in view of Hadzic, U.S. Patent No. 7,130,303 ("Hadzic"), and 
in further view of Mercer et al., U.S. Patent Published Application No. 2003/0018908 
("Mercer"). 1 Claims 5-7, 9 were rejected under 35 U.S.C. § 103(as) as allegedly being 
unpatentable over the combination of Bryers, Hadzic, and Mercer, and in further view of 
Stevens, TCP/IP Illustrated ("Stevens"). Applicants respectfully traverse these 
rejections. Applicants note that the Examiner has not presented a rejection under 35 
U.S.C. 103 for claims 17-33, 35, 36, or 38-40. 

The combination of Bryers, Hadzic, and Mercer fails to teach or suggest each and 
every feature of amended independent claims 1 and 37. The Final Office Action 
acknowledges that Bryers fails "to explicitly recite that one Ethernet packet may 
comprise another Ethernet packet." The Office Action alleges that Hadzic "discloses the 
practice of generating an Ethernet packet comprising another Ethernet packet for 
delivery over large distributed systems." As explained in Applicants' Reply to the Non- 
Final Office Action, Hadzic describes "encapsulating contents of each original Ethernet 
packet, which originates in a first Ethernet network of an entity, e.g., an enterprise, a 
customer, or a network service provider, within another Ethernet packet which is given a 
source address that identifies the new encapsulating packet as originating at a port of a 
switch that is located at the interface between the first Ethernet network in which the 
original Ethernet packet originated and a second Ethernet network, e.g., the metropolitan 
area Ethernet network, which is to transport the encapsulating packet" to the destination. 
(Hadzic, 1 : 44-53.) Thus, Hadzic describes the use of encapsulation for transporting 



1 Applicants note that the Examiner did not include claims 13-15 and 37 in the 
summary statement regarding 35 U.S.C. § 103(a) rejections, but did include arguments as 
why these claims were unpatentable under 35 U.S.C. §103. Therefore, Applicants have 
demonstrated that these claims should be allowed. 
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packets from an originating network to a destination network via an intermediate 
network, such as a metropolitan area Ethernet network. Nowhere does Hadzic describe 
that ''the first Ethernet packet [from an originating device] comprising a second Ethernet 
packet wherein a destination address of the second Ethernet packet is an address of 
the originating device" as recited in independent claim 1 or "the first Ethernet packet 
[from an originating device] comprising a second Ethernet packet including a header 
having an address of the originating device as the destination address/' as recited in 
independent claim 37. 

In the Final Office Action, the Examiner argues "that it may be possible to 
suggest that the applicant's recitation of wherein a destination address of the second 
Ethernet packet is an address of the originating device is simply a reference to the fact 
that an address of a sender may he used by a receiver to send data to the sender," (Final 
Office Action, p, 8.) Applicants respectfully disagree with the Examiner's interpretation. 
The claims clearly recite that the second Ethernet packet is encapsulated in a first 
Ethernet packet. Furthermore, the claims clearly recite that the second Ethernet packet 
received from the originating device has the destination address set to the address of the 
originating device. The receiver does not have to generate a packet with the address of 
the sender to send data to the sender. Instead, the security processor (receiver) strips the 
first Ethernet packet and sends the second Ethernet (inner) packet back to the originating 
device. 

Neither Mercer nor Stevens overcomes the deficiencies of Bryers and Hadzic 
relative to independent claims 1 and 37. Based on the above. Applicants respectfully 
request that the rejection of claims 1-4, 5-7, 9, 13-1 5, 16, and 37 be withdrawn. 

The U.S. Patent and Trademark Office is hereby authorized to charge any fee 
deficiency, or credit any overpayment, to our Deposit Account No. 19-0036, 

Respectfully submitted, 

Sterne, Kessler, Goldstein & Fox p.l.l.c. 

f v> w^,.^ v.>^— < 

5 €<ori Gordon 
Attorney for Applicants 
Registration No. 50,633 

Date: April 14, 2010 



